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Overview 

■ What is IKE? 

■ Internet Key Exchange, part of IPsec 

■ Formal analysis of IKE 

■ Previously considered infeasible 

■ Using Scyther framework and protocol analysis tool 

■ Leveraging massive parallelism / CPU resources 

■ Check security properties relevant for key exchange protocols 

■ Some highlights of results 

■ Is the world safe? 




Ipsec and IKE 

I E T 

■ IPsec: IETF standard for end-to-end security 

■ Part of IPv6, optional extension for IPv4. 

■ IPsec establishes a security association between endpoints 

■ Core element: shared keying material 

■ IKE (Internet Key Exchange) establishes keying material 

■ Stated goals of IKE 

■ Authenticated keying material 

■ Perfect Forward Secrecy 

■ Identity Protection 

■ Mutual authentication 
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Previous analyses of IKE 

■ IKEv1 

■ Meadows, 1999; Perlman, Kaufman, 2000; Zhou, 2000; Canetti, 
Krawczyk, 2001; 

■ Several issues found, some fixed in IKEv2 

■ IKEv2 

■ Drielsma, Moedersheim, 2003; (some subprotocols) 



But why not proof or full analysis? 




"IKE is fairly complicated; to fully understand it, it's 
helpful to possess multiple advanced degrees in 
mathematics and cryptography and to have 
copious amounts of spare time to read many 
detailed yet highly valuable resources." 




Microsoft TechNet: How IPsec works 

Source: http : //technet . mic rosof t . com/en - us/lib ra ry/cc512617 . aspx 
(Retrieved September 1 , 2011 ) 
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Example IKE exchange 



IKEvl Aggressive Mode with digital signatures 

1. A^B: HDRi, 5A,g^\NA,IDA 

2. B^A: HDR2, SA'.g^^.NeJDe, 

{prfK{g''.g'\ CKYb, CKYa, IDB)}sk(B) 

3. A^B: HDR3, {prfK{g-\g-^, CKYa, CKYb, IDA)}sk{A) 

where K = prf^^^^^^ig^^''^). 
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IKEv1 Aggressive Mode with digital signatures 

1. A^B: HDRi, SA,g'\NA.IDA 

2. B^A: HDR2, SA.s^^.Nb.IDb, 

{prfK{g'-',g"\CKYB, CKYa, /Db)},^^) 

3. A^B: HDR3, {prfi,(g-\g-^',CKYA,CKYB,IDA)}.,(A} 



IKEv1 IVIain IVIode with digital signatures 
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IKEv1 Aggressive Mode with digital signatures 



IKEv1 Aggressive IVIode with Pre-shared keys 



IKEv1 Aggressive IVIode with Public keys 



IKEv1 Aggressive Mode with Public keys (2) 



Note: some minor variants omitted! 



IKEv1 Main Mode with digital signatures 



IKEv1 Main Mode with Pre-shared keys 



IKEv1 Main Mode with Public keys 



IKEv1 Main Mode with Public keys (2) 
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Phase 1 



IKEv1 Aggressive Mode with digital signatures 



IKEv1 Aggressive IVIode with Pre-shared keys 



IKEv1 Aggressive IVIode with Public keys 



IKEv1 Aggressive Mode with Public keys (2) 



Phase 2 



IKEv1 Quick Mode 



IKEv1 Quick Mode without Identity 



Note: some minor variants omitted! 



IKEv1 Main Mode with digital signatures 



IKEv1 Main Mode with Pre-shared keys 



IKEv1 Main Mode with Public keys 



IKEv1 Main Mode with Public keys (2) 



IKEv1 Quick Mode without PFS 



IKEv1 



Phase 1 



IKEv1 Aggressive Mode with digital signatures 



IKEv1 Main Mode with digital signatures 



iKEv1 Aggressive Mode with Pre-shared keys 



IKEv1 Main Mode with Pre-shared keys 



iKEv1 Aggressive Mode with Public keys 



IKEv1 Main Mode with Public keys 



IKEv1 Aggressive Mode with Public keys (2) 



IKEv1 Main Mode with Public keys (2) 



Phase 2 



IKEv1 Quick Mode 



IKEv1 Quick Mode without Identity 



IKEv1 Quick IVIode without PFS 



Note: some minor variants omitted! 



IKEv2 



Phase 1 



IKEv2 SIG noid 



IKEv2 MAC noid 



IKEv2 EAP noid 



IKEv2 SIG/MAC asymmetric variants 



IKEv2 SIG/MAC asymmetric variants 



IKEv2 SIG/MAC asymmetric variants 



IKEv2 SIG/MAC asymmetric variants 



Phase 2 



IKEv2 child mode 



IKEv2 child mode without PFS 
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Our approach: formal tools 




k r ^HTW ni ■m^.l. tnl- l r->n> >yF> 1K\ f 



■ Symbolic analysis of security protocols 

■ Model protocol execution in presence of adversary 

■ Verify/falsify that properties hold in all reachable states 

■ Tools: e.g., Avispa, Maude-NPA, ProVerif, Scyther 

■ We use Scyther (Cremers, 2008) 

■ Defines several adversary types that 

■ Completely control the network (Dolev-Yao assumption) 

■ Can learn long-term keys 

■ For AKE experts: this is used to verify PFS, KCI resilience 

■ Can learn (some) session keys 

■ Can learn (some) intermediate computations made by the participants 



eKMisntlston K3 



(About model-checking security protocols:) 

"The state-of-the-art is able to handle [../ 
protocols of realistic, but limited, complexity. A 
fully automatic analysis of the Internet Key 
Exchange Protocol, with all its variations, would 
lead to state explosion and is outside of the 
current state-of-the-art." 





David Basin, Gas Cremers, Catherine IVIeadows 
"Model Checking Security Protocols" [Draft] 
Chapter for the Handbook of Model Checking, to appear 

(Retrieved May 1, 2011) 
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Making analysis of IKE feasible 

■ Ingredients 

■ Scythertool 

■ Brutus cluster (supercomputer at ETH Zurich) 

■ RFC specs of IKE + design documents for IKEv2 

■ Hundreds of pages 

■ Modeling effort: months 

■ Big thanks to Adrian Kyburz for work on the initial models 

■ What to check? Not specified in documentation 

■ Secrecy, authentication with respect to 96 adversary types 

(for AKE experts: this includes Dolev-Yao, BR93, OK, eCK, multi-protocol 
adversaries - see e.g. Basin and Cremers, Esorics 2010) 
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Example: model fragment 

protocol ikevl-sig-al (I , R) { 
role I ■[ 

fresh i, Ni, Ci : Nonce; 
var Nr, Cr: Nonce; 
var Gr: Ticket; 



Adversary comprc^ise model 

Long-term Key Reveal 0 Others (DY) 

Long-term Key Reveal □ Actor (KCI) 

O None (DY) 

Long-term Key Reveal after claim ^ g^ercorrect (wPFS) 



.after (PFS) 



Session-Key Reveal 
Random Reveal 
State Reveal 
Automatically infer local state 



□ 
□ 
□ 



send_l ( I, R, Ci, list, g(i) , Ni, I ); 
recv_!2( R, I, HDR, algo, Gr, Nr, R, {HASH_Ri}sk(R) ); 
claimC I, Running, R, Ni , Nr, g(i) , Gr, Ci, Cr ); 
send_!3( I, R, HDR, {HASH_Ii}sk(I) ); 



claim ( I, SKR, SKi ); 

claim( I, Alive ); 

claim ( I, Weakagree ); 

claim( I, Commit, R, Ni, Nr, g(i) , Gr, Ci, Cr ); 
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Results: summary 

■ Final run: 

■ 3700 lines for protocol models 
(Scyther input language, macros) 

■ Number of tool runs: approx. 50000 

■ Time: 3 days (no Brutus: 1 year!) 

■ Used much more resources while developing models 

■ Resources enabled tool-assisted model development 

■ Security? 

■ Rediscovered vast majority of known attacks 

■ Found several new weaknesses 

■ Bounded verification (for now) 
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Results highlights: secrecy 

■ "Simple" secrecy holds against network attacker 

■ But not any cryptographic security notion 

■ For AKE experts: e.g. BR93, CK, eCK, ... 

■ Main reasons: 

" Vulnerable to reveal of randomness / intermediate computations 

■ Compute same keying material in non-matching sessions 

■ Enables session-key reveal attacks 

■ Vulnerable to Key Compromise Impersonation attacks 

■ May not be problematic in practice 

■ But other protocols are "nnore secure" (e.g., (H)MQV) 
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Results highlights: authentication 

■ Many new weaknesses 

■ ...but often resolved after message exchange (because key is secret 
anyway) 

■ IKEv1 

■ aliveness guaranteed for phase 1 , but nothing more 

■ beliefs may be wrong 

■ IKEv2 

■ Much better 

■ Still no agreement in some subprotocols 

■ Don't use these keys here if you want authentication! 

■ Still no recent aliveness guarantees after Phase 2 exchange 
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Highlight: example of weak authentication 

IKEvl Aggressive Mode with digital signatures 

A talking to B; B talking to C! 

la. A^Ab- HDRi, 5A, g''\ Na, IDa 
lb. Ac^ B : HDRi, 5.4, Na, IDc 

2. B^A: HDR2, SA,g'^,NB,IDB. 

{prW.g''. CKYb, CKYa, IDB)}shiB) 

3. A^B: HDR3, {prfK{g'\g'', CKYa, CKYb, IDA)}skiA) 

B does not accept the last message! 
...but A has already successfully finished 
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Conclusions Wi 

■ Most extensive formal analysis of IKE so far ^ 

■ Formal analysis of standards is possible and useful 

■ New insights in the properties achieved 

■ Don't expect strong authentication or recent aliveness from the IKE 
phases 

■ Hints for provable security - but models still fairly coarse 

■ Methodology scales well for real-world security protocols, 
given sufficient resources 

■ Biggest hurdle: developing good protocol models (faithful 
abstractions) 

■ Having a library of existing analyses helps 

Cas Cremers - cas.cremers@inf.ethz.ch 
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